Method and system to connect internet protocol hosts via an application specific bus

ABSTRACT

The present invention includes a system and method to implement Internet Protocol (IP) hosts on an application specific bus without disrupting the application specific bus. In one embodiment, an IP host determines the application specific bus address of a remote device, the remote device having an IP address in addition to the application specific bus address. The IP host formats a message conforming to the application specific bus, the message containing IP data and message identifiers. The IP host transmits the message on the application specific bus. In addition, the IP host negotiates for network access on the application specific bus. A destination IP host receives the message based upon the application specific bus address of the destination IP host and authenticates the message as an IP messages based upon the message identifiers. In addition, the destination IP host extracts the IP data from the message and processes the IP data by a conventional IP network processing protocol.

FIELD OF THE INVENTION

[0001] The present invention relates to bi-directional communicationover a network and, in particular, relates to a protocol to connectInternet Protocol (IP) hosts via a control bus.

BACKGROUND OF THE INVENTION

[0002] As today's vehicles have become more sophisticated and dependentupon a variety of electronic and electrical components, it has becomenecessary to devise methods of networking the various componentstogether. Communication is needed between the many circuits andfunctions of the vehicle, for example, to shift a transmission inresponse to engine load.

[0003] In order to standardize communications between the variouscomponents of the vehicles, the Controller Area Network (CAN) wasdefined as a serial communications bus. CAN uses a shared broadcast busthat runs at speeds up to one megabit per second. The CAN protocol sendsmessage frames of variable lengths, containing from zero to eight databytes, among various devices within the vehicle wherein each frame has aunique identifier.

[0004] The Society of Automotive Engineers (SAE) has developed astandard CAN protocol, SAEJ1939, for the bus and truck industry, basedupon CAN Specification 2.0 Part B by Robert Bosch, GmbH. The SAEspecification gives plug-and-play capabilities for vehiclemanufacturers. The specification assigns 29 bit frame identifiers fordifferent purposes, such as engine diagnostics and vehicle position, andspecifies a data rate of 250 kilobits per second. Standard SAEJ1939protocols allow modules from many suppliers to be easily linked togetherforming a type of open architecture. An open architecture allowsstandardized diagnostic testing and allows suppliers to benefit from theeconomies of scale of mass-produced standard protocol devices.

[0005] SAEJ1939 uses the CAN protocol which permits any device totransmit a message frame on the network when the bus is idle. Each frameidentifier includes, in order, a field for message priority, a field forthe type of data that the message contains, and a field for the sendingnode's address. The entire 29-bit identifier uniquely establishes theoverall priority of each frame. The protocol avoids collisions on theCAN by an arbitration process that occurs during identifier transmission(using a non-destructive arbitration scheme). This arbitration permitshigher priority messages to get through with lower latency (less delay).

[0006] Subpart SAEJ1939/21 specifies the link layer protocol forSAEJ1939. Other parts of SAEJ1939 define the actual application contentof messages. As such, SAEJ1939 defines a simple two-layer networkingarchitecture, a link layer and an application layer. The link layer(SAEJ1939/21) allows for proprietary messages of arbitrary content to becommunicated. Standard SAEJ1939 devices ignore such messages.

[0007] A computer network is a system for communications among computersthat allows them to share information. The content, scope, size, speed,and reliability of a network varies depending on the protocols andimplementation used. Protocols are preestablished methods ofcommunication between computers. The term TCP/IP (Transmission ControlProtocol/Internet Protocol), refers to a family of protocols of whichTCP and IP are just two. TCP/IP is broken down into a protocol of anumber of layers. Each layer corresponds to a different facet ofcommunication within the network. Devices that communicate using TCP/IPare referred to as IP hosts.

[0008] The link layer is responsible for communicating with actualnetwork hardware. The link layer transfers data, which the link layerreceives from the network bus, to the network layer. The link layer putsdata, which the link layer receives from the network layer, on the bus.Within the SAEJ1939 architecture, the SAEJ1939/21 protocol defines thelink layer.

[0009] The network layer determines how to get data to its destination,either out onto the bus or into application programs. The network layermakes no decision whether or not the data will reach its destination butonly decides where to put the data for transmission. The third layer,the transport layer, provides data flow for the application layer. Thetransport layer guarantees the reliability of the communication. Thefourth or application layer is where the user or IP client or serverprogram interacts with the network. This is where any applicationprograms reside.

[0010] The IP (of TCP/IP) resides on the network layer and is used foralmost all communication between IP hosts. The basic communicationsmessage unit in IP is the IP datagram. When sending datagrams, the IPdetermines how to get the datagrams to their destinations and whenreceiving datagrams, determines how and where they belong. IP does notconcern itself with whether the datagrams arrive reliably at their givendestination or with the order in which they arrive. If a datagramarrives with any problems, IP discards it. It is the responsibility ofthe transport layer and application layer to determine, to correct, orto otherwise deal with the unreliability of datagrams. The IP isresponsible for recognizing source and destination addresses whileensuring receipt at the proper location as well as checking for theaccuracy of datagrams received from the network.

[0011] IP is the most widely used network layer protocol in the world.It is available on almost all of the world's desktop computers, and itis becoming widely used in embedded computers. Software for manyubiquitous transport and application layer protocols that run on top ofIP is widely available for virtually all computer operating systems.

[0012] What is required is a protocol for incorporating IP hosts onto anapplication specific control bus such as a SAEJ1939. Further, what isrequired is a method and apparatus to transmit IP datagrams withoutinterfering with the interaction of standard CAN devices, and,specifically, without interfering with the interaction of standard SAEJ1939 devices.

SUMMARY OF THE INVENTION

[0013] The present invention includes a system and method to implementInternet Protocol (IP) hosts on an application specific bus withoutdisrupting the application specific bus. In one embodiment, theapplication specific bus address of a remote device is determined, theremote device having an IP address in addition to the applicationspecific bus address. An IP host formats a message conforming to theapplication specific bus, the message containing an IP datagram andmessage identifiers. The IP host transmits the message on theapplication specific bus. A destination IP host receives the messagebased upon the application specific bus address of the destination IPhost and authenticates the message as an IP message based upon themessage identifiers. In addition, the destination IP host extracts theIP datagram from the message and processes the IP data by a conventionalIP network processing protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The present invention will be understood more fully from thedetailed description given below and from the accompanying drawings ofthe preferred embodiments of the invention, which, however, should notbe taken to limit the invention to the specific embodiments but are forexplanation and understanding only.

[0015]FIG. 1 is a block diagram illustrating one embodiment of a systemof connecting at least one Internet Protocol (IP) host to a ControllerArea Network (CAN);

[0016]FIG. 2 is a block diagram illustrating an embodiment of CAN/IPhost protocol layers;

[0017]FIG. 3 is a block diagram of an Ethernet Address ResolutionProtocol (ARP) message;

[0018]FIG. 4 is a block diagram of one embodiment of an AddressResolution Protocol (ARP) message;

[0019]FIG. 5 is a flowchart of one embodiment of a process for resolvingCAN/IP message congestion on the CAN;

[0020]FIG. 6 is an example timeline illustrating one example of CAN/IPcongestion control;

[0021]FIG. 7 is a flowchart of one embodiment of a process for receivingCAN/IP protocol messages by the CAN/IP; and

[0022]FIG. 8 is a flowchart of one embodiment of a process for creatingCAN/IP messages for broadcast over the CAN.

DETAILED DESCRIPTION

[0023] The present invention describes a method and system to connectInternet Protocol (IP) hosts to an application specific control bus suchas the Controller Area Network (CAN).

[0024] In the following detailed description of the present invention,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. However, it will be apparent toone skilled in the art that the present invention may be practicedwithout these specific details. In some instances, well-known structuresand devices are shown in block diagram form, rather than in detail, inorder to avoid obscuring the present invention.

[0025] Some portions of the detailed descriptions that follow arepresented in terms of algorithms and symbolic representations ofoperations on data bits within a computer memory. These algorithmicdescriptions and representations are the means used by those skilled inthe data processing arts to most effectively convey the substance oftheir work to others skilled in the art. An algorithm is here, andgenerally, conceived to be a self-consistent sequence of steps leadingto a desired result. The steps are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

[0026] It should be borne in mind, however, that all of these andsimilar terms are to be associated with the appropriate physicalquantities and are merely convenient labels applied to these quantities.Unless specifically stated otherwise as apparent from the followingdiscussions, it is appreciated that throughout the present invention,discussions utilizing terms such as “processing” or “computing” or“calculating” or “determining” or “displaying” or the like, refer to theaction and processes of a computer system, or similar electroniccomputing device, that manipulates and transforms data represented asphysical (electronic) quantities within the computer system's registersand memories into other data similarly represented as physicalquantities within the computer system memories or registers or othersuch information storage, transmission or display devices.

[0027] The present invention also relates to apparatus for performingthe operations herein. This apparatus may be specially constructed forthe required purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. The algorithms and displays presented herein are notinherently related to any particular computer or other apparatus.Various general-purpose machines may be used with programs in accordancewith the teachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these machines will appear from thedescription below. In addition, the present invention is not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the invention as described herein.

[0028]FIG. 1 is a block diagram of the overall system of connectingmultiple CAN/Internet Protocol (CAN/IP) hosts 104 to a Controller AreaNetwork (CAN) 100. In the FIG. 1 illustration, CAN/IP hosts 104 areconnected via CAN bus 120 to CAN 100. CAN/IP host 104 interacts withCAN/IP client or server program 102 through a software interface. In oneembodiment, this is a standard IP socket interface. Also, CAN/IP host104 contains Address Resolution Protocol (ARP) cache 130 for storingresolved addresses of CAN/IP hosts 104 accessible on CAN 100. CAN 100also includes a series of vehicle control modules 106, 108, 110, and 112(CAN devices), all connected via standard CAN interface 140 to CAN bus120. In an alternate embodiment, CAN/IP host 104 and CAN/IP client orserver program 102 may be contained within the same device.

[0029]FIG. 2 is a block diagram illustrating IP host protocol layers200. IP host protocol layers consist of application layer 208, transportlayer 210, network layer 212, link layer 214, and physical layer 220.

[0030] Application layer 208 may consist of standard IP hostapplications such as File Transport Protocol (FTP), Hypertext TransferProtocol (HTTP), and Telnet. These and other application protocols makeuse of the services of standard transport protocols such as TransmissionControl Protocol (TCP) and User Datagram Protocol (UDP) contained withintransport layer 210. Both TCP and UDP make use of the standard servicesof Internet Protocol (IP) at the network layer 212. In one embodiment,the physical layer 220 protocol may be CAN 2.0 B.

[0031] Between network layer 212 and physical layer 220 is link layer214. Link layer 214 has two sub-layers specified by CAN/IP 205 and SAEJ1939/21 (222). SAE J1939/21 (222) specifies a protocol forcommunicating frames containing from zero to eight data bytes on the CANbus as well as a protocol for communicating larger messages using whatis termed the Transport Protocol. Transport Protocol is a standardcommunications protocol of SAEJ1939/21 (222) which breaks large messagesinto seven byte pieces and sends them individually with a sequencenumber.

[0032] In one embodiment, CAN/IP 205 may have four component protocols:Encapsulation Protocol (EP), Authentication Protocol (AP), AddressResolution Protocol (ARP), and Congestion Control Protocol (CCP).

[0033] The EP manages the packing and unpacking of IP datagrams intoSAEJ1939/21 (222) message frames using the SAEJ1939/21 (222) TransportProtocol. In one embodiment, the EP messages containing CAN/IP datagramsuse the SAEJ1939/21 (222) Proprietary A Parameter Group Number(PGN)=61184. This is the SAEJ1939/21 (222) destination-specific ProtocolData Unit (PDU). In one embodiment, each IP datagram may have two bytesadded to aid in message authentication and to indicate message type. Inthis embodiment, an IP datagram has an added first byte set at 16, toindicate a CAN/IP message, and an added second byte set at 0, toindicate a standard IP datagram. In one embodiment, the added secondbyte may be set at 2, to indicate a compressed IP datagram. Each IPdatagram, with header, is transmitted as a single Transport Protocolmessage. In one embodiment, CAN/IP 205 supports IP datagrams withlengths from 28 to 576 bytes. With the two-byte header, the IP datagramsin this embodiment will be transmitted using from 5 to 83 eight-byte CANframes.

[0034] In one embodiment, the AP of CAN/IP host 104 verifies thatSAEJ1939/21 (222) Proprietary A Parameter Group Number (PGN)=61184messages that it receives are in fact CAN/IP 205 messages. In thisembodiment, CAN/IP messages are those messages that have a value of 16in the first information byte.

[0035] When CAN/IP 205 receives a potential CAN/IP message (PGN=61184;first data byte=16), the local Address Resolution Protocol (ARP) cache130 is queried to determine if the corresponding source address isalready in the ARP cache 130. If it is not, CAN/IP 205 requests theSoftware Identification Report (SIR) (PGN=65242) of the source device(i.e., the originator of the message) using the previously receivedsource address. CAN/IP 205 requests the SIR before it accepts themessage as being a valid message from another CAN/IP 205 host. For aCAN/IP host, the SIR response includes a predetermined string such as“CANIP1”. If it does, CAN/IP 205 adds the source address to the ARPcache. If the response does not include the string “CANIP1”, all furtherpotential messages from that source are not interpreted as CAN/IPmessages.

[0036] In one embodiment, once a source address is either accepted orrejected, the status may be maintained until another Address Claimed(PGN=60928) message is received for that source address. At that time,the authentication process is repeated.

[0037] In one embodiment, the AP may also verify message data lengths todetermine if they are either four or in the range 30 to 578 bytes inlength (i.e., an IP datagram plus the two-byte link-layer header).

[0038] CAN/IP 205 uses an Address Resolution Protocol (ARP) similar toEthernet ARP for obtaining and resolving addresses on CAN 100. FIG. 3 isa block diagram of an Ethernet Address Resolution Protocol (ARP)message. FIG. 4 is a block diagram of one embodiment of a CAN/IP ARPmessage.

[0039] The Ethernet ARP message 300 is described in Request For Comment(RFC) 826 from the Internet Architecture Board (IAB). Frame Type 314,Hardware Type 316, Protocol Type 318, Hardware Size 320, and ProtocolSize 322 have fixed values and are not transmitted in CAN/IP ARP message400. In one embodiment, Ethernet Destination Address 310 and TargetEthernet Address 330 may be replaced by the Destination CAN Address 422.In this embodiment, the Ethernet Source Address 312 and Sender EthernetAddress 326 may be replaced by the Source CAN Address 420. DestinationCAN Address 422 and Source CAN Address 420 are part of Arbitration field402.

[0040] The Ethernet Op 324 is not transmitted in CAN/IP ARP 400.Requests or queries are identified by the Destination CAN Address 422being set at the broadcast address (usually 255). Replies are identifiedby the Destination CAN Address 422 not being set at the broadcastaddress.

[0041] In one embodiment, the least significant byte of Sender IPAddress 328 is sent as Sender IP Address LSB 410, and the leastsignificant byte of Target IP Address 332 is sent as Target IP AddressLSB 412. In this embodiment, the most significant three bytes of all IPaddresses on CAN 100 are assumed to be equal for all CAN/IP hosts 104 ona particular instance of CAN 120.

[0042] The truncated fields of CAN/IP ARP message 400 have the samevalues and meanings as the corresponding fields in Ethernet ARP message300. In one embodiment, CAN/IP ID 406 is set at 16 and Frame Type 408 isset at 1.

[0043] In CAN/IP ARP message 400, Arbitration 402, Control 404, andTrailer 414 have standard formats and meanings according to SAEJ1939. Inone embodiment, the SAE J1939/21 (222) PGN is 61184.

[0044] In one embodiment, after CAN/IP 205 successfully claims its linklayer address and determines its CAN/IP address, it transmits a CAN/IPARP request for its own CAN/IP address.

[0045] CAN/IP 205 limits network access using CCP. During periods ofcongestion on the network, the CAN priority mechanism always givesnetwork access to the highest priority message and no two messages canhave equal priority. Thus, because it is desirable for all CAN/IP Hosts104 to have equivalent access to the CAN 120, the CAN priority mechanismmay be circumvented using CCP.

[0046]FIG. 5 is a flowchart of one embodiment for determining theMulti-Packet Transport Protocol Rate Limit (MPTPRL) of CongestionControl Protocol (CCP) of CAN/IP 205. Initially, at step 705, CCP beginsmaintaining an averaging interval (I). In one embodiment, I may be a100-millisecond interval. At step 710, CCP determines if the averaginginterval started in step 705 is complete. If the averaging interval iscomplete, CCP continues processing at step 720. However, if CCPdetermines that the averaging interval is not complete, CCP continuesprocessing at step 715. At step 715, CCP counts the frames (PI) of alltypes on, CAN 120 from all sources.

[0047] If, at step 710, CCP determines that I is complete, CCP adjuststhe MPTPRL at steps 720 through 735. At step 720, CCP determines if thetotal number of frames (PI) determined in steps 710 and 715 is greaterthan 0.9 times the network capacity for packet transmission. If not, CCPcontinues processing at step 730. If CCP determines that PI is greaterthan 0.9 times network capacity, CCP continues processing at step 725.In one embodiment, network capacity is assumed to be 200 frames per100-millisecond interval.

[0048] At step 725, CCP decreases MPTPRL. In one embodiment, MPTRL takesa value from the ordered set comprising a series 80, 40, 27, 20, 16, 13,11, 10, 9, 8, 7, 6, 5, 4, 3, 2. In this embodiment, CCP decreases MPTRLby changing its value to the next value to the right of the currentvalue in the ordered set. CCP then returns to step 705 to begin a newaveraging interval.

[0049] If, at step 720, CCP determines that PI is not greater than 0.9times network capacity, CCP continues processing at step 730. At step730, CCP determines if PI is less than 0.8 times network capacity. Ifnot, CCP returns to step 705 to begin a new averaging interval. If, atstep 730, PI is less than 0.8 times capacity, CCP continues processingat step 735. At step 735, CCP increases the MPTPRL. In one embodiment,using the same series as in step 725, CCP increases MPTPRL by changingits value to the next value to the left of the current value in theordered set. CCP then returns to step 705 to begin a new averaginginterval.

[0050] The value of MPTPRL as determined above is used by CCP to controlthe number of multi-packet transport protocol frames (PGN=60160 or60416) that are transmitted by CAN/IP 205. In one embodiment, CCP uses a100-millisecond interval and assumes the network capacity is 200 framesduring this interval. The current MPTPRL is used as a percentage andmultiplied by the assumed capacity to determine its limit. If during aninterval, CAN/IP 205 transmits its limit of multi-packet transportprotocol frames, it will stop transmitting them until the next intervalbegins. Transmissions of other frame types are not affected by MPTPRL.

[0051]FIG. 6 illustrates, by way of example, a time line indicating howCCP limits transmission in CAN/IP Host 820 according to MPTPRL 822. Attime=0, MPTPRL 822 has a value 80. Limit 824 is 160 (80% of 200=160). Atthe beginning of Interval 1, CAN Device 810 transmits 100 frames. At theend of Interval 1, CAN/IP Host 820 transmits 100 frames. In Interval 1,CAN/IP Host 820 does not reach its Limit 824 of 160 frames. At 100milliseconds, MPTPRL 822 changes to 40 and Limit 824 changes to 80 (40%of 200). At the beginning of Interval 2, CAN/IP Host 820 transmits 80more multi-packet transport protocol frames and stops because it hasreached its limit. CAN Device 810 then transmits 90 more frames. At 200milliseconds, MPTPRL 822 and Limit 824 remain unchanged. At thebeginning of Interval 3, CAN/IP Host 820 completes its transmission bytransmitting an additional 50 frames.

[0052]FIG. 7 is a flowchart of one embodiment of a method for processinga message received from Controller Area Network (CAN) 120. Initially, atstep 505, CAN/IP 205 receives a message to process. In one embodiment,only messages with PGN equal to 61184 and with a first data byte equalto the CAN/IP indicator (a value of 16) are accepted as potential CAN/IPmessages. In one embodiment, the length of the message may also beverified to be either 4 or in the range of 30 to 578 bytes, inclusive.In one embodiment, messages that are not accepted as potential CAN/IPmessages may be processed according to other protocols, such as SAEJ1939application messages.

[0053] Next, at step 510, CAN/IP 205 authenticates the potential IPmessage using Authentication Protocol (AP). CAN/IP 205 performs a cachelookup of the CAN source address in the ARP cache 130. The ARP cache 130contains the CAN addresses of CAN/IP Hosts 104 known to be accessible onCAN 100. If the address is in the ARP cache 130, then CAN/IP 205continues processing at step 515. However, if the address is not in thecache, CAN/IP 205 transmits a request or query to the sending device toverify that the message is indeed a CAN/IP message.

[0054] In one embodiment, CAN/IP 205 uses a standard SAEJ1939 messagetype to request the SIR of the sending device. CAN/IP 205 receives theSIR and, if the SIR response verifies that the message is an IP message(because the sending device is a CAN/IP host), CAN/IP 205 places theaddress of the sending CAN/IP host in ARP cache 130.

[0055] At step 515, CAN/IP 205 checks the frame type of the receivedmessage. If the frame type is an ARP reply, CAN/IP 205 enters the SenderIP Address 410 into ARP Cache 130 at step 520. If the frame type is anARP request, and the requested IP address belongs to CAN/IP Host 104,then an ARP reply is transmitted back to the sender at step 525. If theframe type is an IP datagram, CAN/IP 205 extracts the IP datagram fromthe CAN/IP message at step 530.

[0056] At step 530, CAN/IP 205 sends the IP datagram to the IP layer 212to process the IP datagram by any conventional processing protocol.

[0057]FIG. 8 is a flowchart of one embodiment for transmitting CAN/IPdatagrams onto CAN 100. Initially at step 605, IP layer 212 uses the IPdatagram's destination address to determine the Next Hop IP addressusing conventional routing protocols.

[0058] At step 608, CAN/IP 205 determines the destination CAN address.If the Next Hop IP address is a broadcast address, CAN/IP 205 uses theCAN global address (255) as the destination CAN address. In oneembodiment, if the Next Hop IP address is a multi-cast addresses (aclass D address), CAN/IP 205 also uses the CAN global address (255) asthe destination address. If the Next Hop IP address is a unicastaddress, CAN/IP 205 uses ARP to determine the destination CAN address.

[0059] At step 610, CAN/IP formats the IP datagram. In one embodiment, aone byte IP identifier and a one byte frame type are appended to thebeginning of the data. In one embodiment, the frame type may be set at 0to indicate an IP datagram.

[0060] At step 615, CAN/IP 205 transmits the IP datagram to the Next HopIP host. CAN/IP 205 uses SAEJ1939/21 multipacket protocol to transmitthe IP datagram in packets of seven data bytes at a time. Duringtransmission, CAN/IP 205 limits the number of frames it transmits pertime interval using CCP as described above. In one embodiment, IPdatagrams are transmitted with their priority bits set at 7 to avoidinterfering with standard SAEJ1939 data traffic.

[0061] Several variations in the implementation for a system and methodto connect Internet Protocol (IP) hosts to a Controller Area Network(CAN) have been described.

[0062] The specific arrangements and methods herein are merelyillustrative of the principles of this invention. Numerous modificationsin form and detail may be made by those skilled in the art withoutdeparting from the true spirit and scope of the invention.

[0063] Although this invention has been shown in relation to aparticular embodiment, it should not be considered so limited. Rather,it is limited only by the appended claims.

What is claimed is:
 1. A method of implementing Internet Protocol (IP)hosts on an application specific bus without disrupting the applicationspecific bus comprising: determining an application specific bus addressof a remote device, said remote device having an IP address in additionto the application specific bus address; formatting a message conformingto the application specific bus, said message containing an IP datagramand message identifiers; transmitting the message on the applicationspecific bus; receiving the message at the remote device based upon theapplication specific bus address; authenticating the message as an IPmessage based upon the message identifiers; and extracting the IPdatagram from the message and processing the IP datagram by aconventional IP network processing protocol.
 2. The method of claim 1wherein the step of determining further comprises: formatting anapplication specific bus address request message; transmitting theaddress request message on the application specific bus; and receivingan address reply message, the reply message containing the applicationspecific bus address of the remote device.
 3. The method of claim 2wherein the address reply message is received from the remote device. 4.The method of claim 1 wherein the step of transmitting furthercomprises: maintaining an averaging interval by at least one IP host;determining a total number of frames of all types present on theapplication specific bus from all sources during the averaging interval;and adjusting a protocol rate limit at the end of the averaginginterval.
 5. The method of claim 4 wherein adjusting a protocol ratelimit further comprises: if the total number of frames is greater than0.9 times a network capacity, decreasing the protocol rate limit; and ifthe total number of frames is less than 0.8 times the network capacity,increasing the protocol rate limit.
 6. The method of claim 4 wherein theat least one IP host uses less than protocol rate limit percent of anapplication specific bus capacity to transmit frames using the protocolrate limit.
 7. The method of claim 6 wherein the application specificbus capacity is 2000 frames per second.
 8. The method of claim 1 whereinthe step of authenticating further comprises: looking-up the applicationspecific bus address for the remote device in a cache; and if theapplication specific bus address for the device is not found in thecache, formatting an application specific bus query message,transmitting the query message on the application specific bus,receiving a query reply message comprising the application specific busaddress for the remote device, and adding the application specific busaddress for the remote device to the cache.
 9. A method of implementingInternet Protocol (IP) hosts on an application specific bus withoutdisrupting operation of the application specific bus, comprising:determining an application specific bus address of a remote device, saidremote device having an IP address in addition to the applicationspecific bus address; formatting a message conforming to the applicationspecific bus, said message containing an IP datagram and messageidentifiers; and transmitting the message on the application specificbus.
 10. The method of claim 9 wherein the step of determining furthercomprises: formatting an application specific bus address requestmessage; transmitting the address request message on the applicationspecific bus; and receiving an address reply message, the reply messagecontaining the application specific bus address of the remote device.11. The method of claim 10 wherein the address reply message is receivedfrom the remote device.
 12. The method of claim 9 wherein the step oftransmitting further comprises: maintaining an averaging interval by atleast one IP host; determining a total number of frames of all typespresent on the application specific bus from all sources during theaveraging interval; and adjusting a protocol rate limit at the end ofthe averaging interval.
 13. The method of claim 12, wherein adjusting aprotocol rate limit further comprises: if the total number of frames isgreater than 0.9 times a network capacity, decreasing the protocol ratelimit; and if the total number of frames is less than 0.8 times thenetwork capacity, increasing the protocol rate limit.
 14. The method ofclaim 12, wherein the at least one IP host uses less than protocol ratelimit percent of an application specific bus capacity to transmit framesusing the protocol rate limit.
 15. A method of implementing InternetProtocol (IP) hosts on an application specific bus without disruptingthe application specific bus, comprising: receiving a message based uponan application specific bus address, said message including an IPdatagram and message identifiers; authenticating the message as an IPmessage based upon the message identifiers; and extracting the IPdatagram from the message and processing the IP datagram by aconventional IP network processing protocol.
 16. The method of claim 15wherein the step of authenticating further comprises: looking-up theapplication specific bus address for the remote device in a cache; andif the application specific bus address for the device is not found inthe cache, formatting an application specific bus query message,transmitting the query message on the application specific bus,receiving a query reply message, and adding the application specific busaddress for the remote device to the cache.
 17. A method of implementingInternet Protocol (IP) hosts on an application specific bus withoutdisrupting the application specific bus comprising: providing a set ofIP hosts, each of said set of IP hosts having an IP address and anapplication specific bus address; receiving a data message from anapplication within one of the set of IP hosts; formatting a transmittalmessage conforming to the application specific bus, said transmittalmessage containing the data message and message identifiers; andtransmitting the data message on the application specific bus to asecond of one of the set of IP hosts based upon an application specificbus address of the second of one of the set of IP hosts.
 18. A method ofimplementing Internet Protocol (IP) hosts on an application specific buswithout disrupting the application specific bus comprising: receiving arequest that a datagram be sent to an IP host identified by an IPnetwork address, the IP address contained within the request; requestinga physical address for a control-based network device corresponding tothe IP address; receiving a reply message from the network devicecontaining the physical address; and transmitting IP packets over thecontrol-based network in a manner appropriate to the control-basednetwork.
 19. A computer-readable medium comprising program instructionsfor implementing Internet Protocol (IP) hosts on an application specificbus without disrupting the application specific bus by performing thesteps of: determining an application specific bus address of a remotedevice, said remote device having an IP address in addition to theapplication specific bus address; formatting a message conforming to theapplication specific bus, said message containing an IP datagram andmessage identifiers; and transmitting the message on the applicationspecific bus.
 20. The medium of claim 19 wherein the step of determiningfurther comprises: formatting an application specific bus addressrequest message; transmitting the address request message on theapplication specific bus; and receiving an address reply message, thereply message containing the application specific bus address of theremote device.
 21. The medium of claim 19 wherein the step oftransmitting further comprises: maintaining an averaging interval by atleast one IP host; determining a total number of frames of all typespresent on the application specific bus from all sources during theaveraging interval; and adjusting a protocol rate limit at the end ofthe averaging interval.
 22. A computer-readable medium comprisingprogram instructions for implementing Internet Protocol (IP) hosts on anapplication specific bus without disrupting the application specific busby performing the steps of: receiving a message based upon anapplication specific bus address, said message including IP data andmessage identifiers; authenticating the message as an IP message basedupon the message identifiers; and extracting the IP data from themessage and processing the IP data by a conventional IP networkprocessing protocol.
 23. The medium of claim 22 wherein the step ofauthenticating further comprises: looking-up the application specificbus address for the remote device in a cache; and if the applicationspecific bus address for the device is not found in the cache,formatting an application specific bus query message, transmitting thequery message on the application specific bus, receiving a query replymessage, and adding the application specific bus address for the remotedevice to the cache.
 24. A system for implementing Internet Protocol(IP) hosts on an application specific bus without disrupting operationof the application specific bus, comprising: means for determining anapplication specific bus address of a remote device, said remote devicehaving an IP address in addition to the application specific busaddress; means for formatting a message conforming to the applicationspecific bus, said message containing IP data and message identifiers;and means for transmitting the message on the application specific bus.25. A system for implementing Internet Protocol (IP) hosts on anapplication specific bus without disrupting the application specificbus, comprising: means for receiving a message based upon an applicationspecific bus address, said message including IP data and messageidentifiers; means for authenticating the message as an IP message basedupon the message identifiers; and means for extracting the IP data fromthe message and processing the IP data by a conventional IP networkprocessing protocol.
 26. A system for implementing Internet Protocol(IP) hosts on an application specific bus without disrupting theapplication specific bus comprising: a message formatted according tothe application specific bus, said message containing IP data andmessage identifiers; at least one source IP host connected to theapplication specific bus, said at least one source IP host places themessage on the application specific bus; and at least one destination IPhost connected to the application specific bus, said at least onedestination IP host having an IP address and an application specific busaddress, said at least one destination IP host receives the messagebased upon the application specific bus address, authenticates themessage as an IP message based upon the message identifiers, andextracts the IP data from the message.
 27. The system of claim 26wherein the at least one source IP host further formats an applicationspecific bus address request message; transmits the address requestmessage on the application specific bus; and receives an address replymessage, the reply message containing the application specific busaddress of the at least one destination IP host.
 28. The system of claim26 wherein the at least one source IP host further maintains anaveraging interval; determines a total number of frames of all typespresent on the application specific bus from all sources during theaveraging interval; and adjusts a protocol rate limit at the end of theaveraging interval, the at least one source IP host uses less thanprotocol rate limit percent of an application specific bus capacity totransmit the frames.
 29. A system for implementing Internet Protocol(IP) hosts on an application specific bus without disrupting operationof the application specific bus, comprising: a message formattedaccording to the application specific bus, said message containing IPdata and message identifiers, the message identifiers used toauthenticate the message as an IP message; and at least one IP hostconnected to the application specific bus, said at least one IP hostconfigured to transmit the message on the application specific bus. 30.The system of claim 29 wherein the at least one IP host is furtherconfigured to format an application specific bus address requestmessage; transmit the address request message on the applicationspecific bus; and receive an address reply message, the reply messagecontaining the application specific bus address of a remote device. 31.A system for implementing Internet Protocol (IP) hosts on an applicationspecific bus without disrupting the application specific bus comprising:a message formatted according to the application specific bus, saidmessage containing IP data and message identifiers; at least one IP hostconnected to the application specific bus, said at least one IP hosthaving an IP address and an application specific bus address, said atleast one IP host configured to receive the message based upon theapplication specific bus address, authenticate the message as an IPmessage based upon the message identifiers, and extract the IP data fromthe message.
 32. The system of claim 31 wherein the at least onedestination IP host further comprises: a cache containing applicationspecific bus addresses for remote devices for authenticating themessage.
 33. The system of claim 32 wherein the at least one destinationIP host is further configured to look-up the application specific busaddress for the remote device in the cache; if the application specificbus address for the device is not found in the cache, the at least onedestination IP host is further configured to format an applicationspecific bus query message, transmit the query message on theapplication specific bus, receive a query reply message, and add theapplication specific bus address for the remote device to the cache.